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IN THE UNITED STATES PATENT AND TRADEMARK OFFICE 



In re Application of 

Jeffery M. Enright, et al. 

Application No.: 09/414,290 

Confirmation No.: 3095 

Filed: October 7, 1999 

Title: Remote Viewing of ATM 

Transaction Records 

Commissioner for Patents 
P.O. Box 1450 
Alexandria, VA 22313-1450 

DECLARATION PURSUANT TO 37 C.F.R. § 1.131 

Sir: 

We, Jeffery M. Enright and Roy Hathaway, hereby declare as follows: 

L At all times relevant we were employed with Diebold, Incorporated ("Diebold") 

the Assignee of the above-identified patent application. We are authorized on behalf of Diebold 

to present this Declaration. 

2. We are joint inventors of the invention set forth in the above-identified patent 

application and have personal knowledge of the facts set forth herein. We are the sole inventors 

of the subject matter described and claimed in at least claims 1,38, and 41 thereof. 
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Art Unit 3628 

Patent Examiner 
David Vincent 



3. At a time prior to March 19, 1998 we conceived of an invention which included 
an automated banking machine, such as an automated teller machine ("ATM") that included 
transaction function devices (e.g., a currency dispenser). A camera would be located adjacent 
the ATM. The camera would produce camera signals corresponding to an image of a person 
located adjacent the ATM. Image data corresponding to the image of the person would be stored 
(via a computer) in a data store responsive to operation of a selected transaction function device 
of the ATM. A computer terminal having a display device would be remotely located from the 
ATM. The terminal would be able to retrieve image data stored in the data store via a network. 
The terminal would be able to display images on the display device corresponding to retrieved 
image data. The retrieval date of image data could be later than the storage date of the image 
data. This idea was conceived of by us in the course of our employment with Diebold. 

4. After conceiving of this invention, we and other eventual inventors attended 
project meetings at Diebold in Canton, Ohio prior to March 19, 1998 to discuss the making of an 
apparatus in accordance with our conceived invention. 

5. Prior to March 19, 1998, we and other inventors at Diebold in Canton, Ohio 
prepared a description of apparatus features in accordance with the invention. An example of 
evidence of the inventive apparatus features is shown in the attachment labeled as Exhibit A. 
Dates in Exhibit A which have been deleted, are all prior to March 19, 1998. 

Exhibit A shows the apparatus capabilities relating to a digital video recorder (DVR) 
associated with an ATM (page 1). The DVR is connected to at least one camera and can use 
motion detection or ATM ExpressBus (internal ATM signals that correspond to transaction 
functions) monitoring to begin capture of data that corresponds to images (pages 3, 13, 14). The 
image data can be stored (and dated) along with ATM transaction data (pages 3, 13, 14). The 
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image data can be retrieved from storage via a browser/network arrangement (pages 3, 13, 14). 
Image capture can also be based on soft alarms, including those noted from monitoring high side 
ATM communications (page 4), which are the communications between the ATM and a remote 
host computer that authorizes transactions at the ATM. 

6. Evidence for design of the inventive apparatus is shown in the detailed 
development outline attached as Exhibit B. The date assigned to Exhibit B (which was deleted) 
was prior to March 19, 1998. The dates mentioned in Exhibit B have also been deleted. Exhibit 
B documents hardware and software capabilities for the inventive apparatus. Exhibit B also 
shows a detailed schedule for reducing to practice the inventive apparatus. The dates for the 
building of the first, second and third preproduction apparatus for testing purposes (line IDs 92, 
120 and 145, respectively) and the "Alpha" and "Beta" tests of the inventive apparatus (line IDs: 
163 and 165, respectively) were scheduled for completion, and in fact were successfully 
completed, prior to March 19, 1998. All dates on line IDs 92, 120, 145, 163 and 165 which have 
been deleted, are prior to March 19, 1998. 

7. Exhibit C shows an e-mail communication involving the herein Declarants. The 
date of the e-mail and any date mentioned therein (which have all been deleted) are all prior to 
March 19, 1998. Exhibit C refers to the inventive apparatus as "DVR." Exhibit C further shows 
that development of the inventive apparatus achieved such an advanced stage that parts for 30 
prototypes were being ordered. 

8. Exhibit D shows specification details for the inventive apparatus with questions 
from the Diebold SQA (Systems Quality Assurance) function related to testing the inventive 
apparatus for performance and reliability. The date of Exhibit D, which has been deleted, was 
prior to March 19, 1998. Exhibit D shows the inventive DVR system (apparatus) including an 
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ATM, cameras, DVR, and a remote terminal (e.g., page 2; Figure 1). The DVR includes web 
server software. The DVR can monitor an ATM, capture and store digital images, and allow the 
stored images to be viewed by a remote terminal using web browser software. 

Exhibit D also shows that the DVR can monitor or eavesdrop on the ATM with regard to 
transaction information (e.g., RS485 or RS232 interfaces; page 9). The DVR can also capture 
and locally process digital images (page 12). The processing can include the linking of 
transaction data and image data. The DVR can also store linked data as records in a database 
(page 12). Image capture can be triggered based on motion detection adjacent the ATM (pages 
15, 17, 21) or hard/soft alarms (page 17). A trigger for image capture can make use of an 
ExpressBus (internal ATM signals) interface or Hi-side (ATM to remote host computer) 
communications. Thus, certain transaction-related messages to a remote host computer in 
certain message formats (e.g., Diebold 911/912, NCR Native, IBM 473x) sent by an ATM can 
trigger image capture (page 20). 

Exhibit D further shows that the DVR can communicate (e.g., via RS232, LAN, Internet) 
with a remote viewing terminal (page 19). Retrieval and playback display of a stored image 
(section 5.2.13) can be selected based on the image's link to other stored data, including an 
associated date/time, transaction data, a camera number, or account data (page 22). 

9. Prior to March 19, 1998 while working at a facility of Diebold, in Canton, Ohio 
USA, we made (or oversaw and directed the making of), operated, and performed testing on 
system features and components and the operation thereof, as recited in at least claims 1,38 and 
41 of the above-identified patent application. 

10 . Testing conducted prior to March 19, 1998 was determined to be successful, and 
established that the invention that is recited in at least claims 1,38, and 41 of the above- 



identified patent application would work for its intended purposes. The successful testing 
included the apparatus features recited in at least claims 1, 38, and 41. That is, the successfully 
tested system comprised an apparatus that at least included: 

A camera adjacent an ATM. A computer connected with the ATM and the 
camera. The computer included a server in connection with a data store. The 
computer could cause image data corresponding to signals captured by the camera 
to be stored in the data store responsive to the ATM carrying out a transaction 
function. The server and a remote user terminal were in connection with a 
communication network. The user terminal included a browser and a display 
device. The user terminal could communicate over the network with the server 
through the browser to retrieve image data in the data store for output through the 
display device. The image data could be displayed subsequent to its storage. 

11 . Exhibit E shows that a successful demonstration of the actual DVR system 
product (including image retrieval capability) was carried out at a facility of Diebold. The date 
of Exhibit E (which has been deleted) was prior to March 19, 1998. Exhibit E also refers to 
another DVR system demonstration for the Bank of Hawaii which was scheduled for and which 
was successfully conducted to demonstrate the inventive apparatus of at least claims 1, 38 and 
41 prior to March 19, 1998. 

12 . Exhibit F shows a request to pursue patent protection for the DVR system. 
Exhibit F refers to a specific date on which occurred a Patent Investigation Meeting. All dates in 
Exhibit F have been deleted. The referred to date of the Meeting was prior to March 19, 1998. 

Exhibit F reiterates features of the DVR system (which was given the name 
"AccuTrack"). These features include ATM transaction based triggers for image capture; 
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storage of captured images; and remote access to these stored images. 

13 . As can be seen from Exhibits A-F, the invention recited in at least claims 1, 38, 
and 41 was completed by being conceived and reduced to practice in the U.S. prior to March 19, 
1998. That is, the successful design, testing, and operation of the invention recited in at least 
claims 1, 38, and 41 resulted in an actual reduction to practice in the U.S. prior to March 19, 
1998. Thus, invention has been established prior to March 19, 1998 for the recited subject 
matter of at least claims 1, 38, and 41. 

14. Although the date of the invention recited in at least claims 1, 38, and 41 has 
above already been established as being prior to March 19, 1998 as discussed above, the process 
of legally protecting the invention continued. As a result of the Meeting (which occurred prior 
to March 19, 1998), the subject matter corresponding to at least recited claims 1,38, and 41 was 
for example filed in U.S. patent application number 60/103,731 on October 9, 1998. 

The filing of application number 60/103,731 constitutes an example of a constructive 
reduction to practice of the invention claimed in at least claims 1,38, and 41. Thus, conception 
of the invention (recited in at least claims 1, 38, and 41) prior to March 19, 1998, coupled with 
due diligence leading to the filing of the invention in application number 60/103,73 1, 
additionally establishes that the invention is prior to March 19, 1998. 

15. We each hereby declare that all statements herein of our own knowledge are true, 
that all statements made on information and belief are believed to be true, and that the statements 
are made with the knowledge that willful false statements and the like so made are punishable by 
fine or imprisonment, or both (18 U.S.C.§ 1001), and may jeopardize the validity of the 
application or any patent issuing thereon. 
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oy Hatj^£way / 



Jeffery M. Enright Roy Hat^fiway 

1-5-06 

Date Date 
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1. SCOPE 



This document will discuss the time (man-power and duration) and materials (contract money is included in 
materials) needed for the Phase #1 development of the Digital Video Recorder project This will be 
simultaneous development of the Branch and ATM Internal DVRs. 

This document is composed of the following sections: 

• Section #2 describes the schedule and how it is broken up 

• Section #3 is a breakdown of the task to be done 

• Section #4 is a breakdown of the functionality included in each build 

• Section #5 is a breakdown of the manpower needed 

• Section #6 is an estimate of the materials needed for development 

• Section #7 is a rougji estimate of the target raw cost for the Branch DVR and the ATM Internal 
DVR 

• Section #8 is a breakdown of the amount of money needed for development 

• Section #9 is a summary of this document 



2. SCHEDULE 



The Digital Video Recorder project will be broken into three phases. Each phase represents a level of 
priority from the Marketing Meeting inputs which are specified in the Product Requirements Specification. 
Phase #1 will be all high priority features (as described within this document), Phase #2 will be priority and 
Phase #3 will be the remainder. Phase #2 and #3 will be described separately in later documents. 

Each phase will be broken into builds. Each build will be a testable product, but will not b e released. The 
products will be released at the completion of each phase. 

Build #1 of Phase #1 will be targeted for a PC platform. Part of Build #2 will be porting Build #1 to a PC 
platform running OS/2. 

Attached at the end of the document is a more detailed breakdown of the schedule. 
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3. TASKS 



The tasks which will be completed within this phase of the DVR Project are described in this section. 

Hardware Evaluation and Hardware Finalization - evaluation and selection of all hardware necessary for the 
Branch and ATM Internal DVRs. At the completion of this task, all hardware will be documented for the 
Branch and ATM Internal DVR's. 

Enclosure Design and Regulatory Testing - the design and testing of the Branch DVR enclosure. At the 
completion of this task, the Branch DVR enclosure will be completed and approved by die testing agencies. 

Software Component Evaluation and Selection - evaluation and selection of all off-the-shelf software 
components necessary for the Branch and ATM Internal DVRs. Software needed that will not run on the 
ATM platform must have a separate package selected (e.g. Web Server, Database, etc.). At the completion of 
this task, all software components will be selected and documented for the Branch and ATM Internal 
DVR's. 

High Level System Design, - this is the preliminary design done on the system. Outputs from this task will be 
Use Cases, Preliminary Domain Object Model, Scenario Diagrams, State Transition Diagrams and High 
Level System Diagrams. 

Software Design and Evolution - design, code and testing of the software needed for the Branch and ATM 
Internal DVRs. 

SQA - all SQA testing as well as Jim Lowry facilitating biweekly and an SQA member attending design 
reviews. 

Alpha and Beta Testing - an Alpha Test will be performed internally and a site will be selected for a Beta 
Test 

PQCuynetitetion " u<ie Technical Publications group will be responsible for writing the Installation, Operator's 
Guide and Service Manuals for the Branch and ATM Internal DVR's. 

Software Release - process of releasing the software for the Branch and ATM Internal DVR's. At the 
completion of this task, the software will be released and available on the market. 

Sales Tools - this task will be generating a set of demo disks for the sales force to demonstrate the products 
to potential customers. 



Company Confidential 



Rev. 1.5 
2 



4. FUNCTIONALITY 



The functionality of what each build will include is listed below. 
Build #1 of the DVR will include the following functionality: 

■ Targeted platform will be a standard PC 

■ Connection to unit using an Internet Browser (such as Netscape) over a dial-up line 
(modem): 

■ Limited configuration 

■ Image retrieval 

■ Limited quick search capability 

■ Single camera playback 

■ On-line help 

■ Images stored on removable media with transaction data 

■ Expressbus monitoring from a single ATM 

■ Soft alarms from expressbus monitoring 

■ Image security 

■ Motion detection 

■ Programmable number of images 

■ Local configuration for implemented features 

■ Diagnostics for implemented features 

■ English language 
Build #2: 

■ Build #1 running on ATM 

. DLL for ATM Internal DVR 

■ Connection to unit over a network connection (either Ethernet or Token-Ring, 
whichever is not done here will be done in Build #3) to perform following operations 
on Branch DVR 

■ More configuration options 

■ View alarm logs 

■ Multi-cameraplayback 

■ Image and data removal linked to date 

■ User defaults 

■ Additional quick search capability 

■ System security (users/passwords) 
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■ Image printing 

■ Support multiple cameras on Branch DVR 

■ Hardware alarms with alarms logged to a log file 

■ Image compression in software 

■ Vary compression rate on alarm condition 

■ Prealarm image storage 

■ Camera/event scheduling 

■ Internal clock synchronized with ATM clock 

■ Local disk level warning 

■ Log of non-recording times maintained in a log file 

■ Singje camera playback on CCTV monitor on Branch DVR 

■ Higjh side communications monitoring from a single ATM (one protocol) on Branch 
DVR 

■ Soft alarms from higfr side monitoring on Branch DVR 

■ E-Mail alarm conditions 

■ Additional local configuration for build #2 features 

■ Additional diagnostics for build #2 features 
Bu3d#3: 

■ Connection to unit using a direct serial connection and die network connection not 
done in Build #2: 

■ Full configuration 

■ View multiple alarm logs 

■ Full diagnostics done remotely 

■ Remote software updates 

■ Default program "scripts" for niche markets 

■ Full search capability 

■ Full system security (users/passwords) 

■ Image and data printing 

■ Network connection for ATM Internal DVR 

■ Integration with custom enclosure for Branch DVR 

■ Indicators on enclosure 
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■ Programmable video output 

■ Additional camera support 

■ Additional alarm support 

■ Partitioning of the storage media 

■ Automatic daylight savings time option 

■ Power loss E-Mail 

■ Multiple ATM monitoring (higjh and low sides) for Branch DVR 

■ Onsite verification of operation 

■ All configuration complete - local and remote 

■ All diagnostics complete - local and remote 
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5. MANPOWER 



This section defines the manpower breakdown needed for Phase #1 of the Digital Video RecorderProject. 

■ 4 full-time Software Engineers for the duration of the project, 1 Software Engineer 50% 
initially, 65% for Build #1 and full-time for the remainder of the project. 

■ 2 co-ops utilized at 50% during the selection of the hardware for the Branch DVR 

■ 1 draftsman utilized at 25% for documenting the release of the hardware and software. 

■ 1 Mechanical Engineer to design the Branch enclosure. 

■ Interbold assistance in regulatory testing ATM Internal hardware integration and ATM 
Internal software development/integration. Interbold will also be responsible for 
making modifications to the ATM software to communicate with the ATM Internal 
DVR. 

■ 1 SQA participant in die role as the team's facilitator. 

■ 2 SQA individuals for testing. 

■ 1 Technical Writer for documentation. 

A more detailed breakdown of the required manpower follows in the appendix. 
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6. MATERIALS ESTIMATE 



This table breaks down materials needed for the development of the Branch DVR 





MAlhiKiAL. 


SXT T A TVT' I'lM'V 


JrKlUi 


T'/YT' A T PACT 1 

TOTAL LOoT 


Power Supply 


5 


$100 


$500.00 


Motherboard 


5 


$500 


<!).a^aa aa 

$2500.00 


Removable Media 


5 


$500 


$2500.00 


Data Cartridges 


10 


$100 


/fttst aaa aa 

$1000.00 


Floppy Drive 


5 


$20 


AA AA 

$100.00 


Hard Drive 


5 


$500 


$2500.00 


Cables 




$300 


* $300.00 


T*\ t 111 V > 

Buttons, LED s 5 etc. 




$200 


$200.00 


LAN Card 


5 


$100 


$500.00 


Modem 


5 


$100 


<fl» a a aa 

$500.00 


Frame Grabber Card 


5 


$500 


$2500.00 


RS-485 Card 


5 


$250 


$1250.00 


RS-232Card 


5 


$100 


$500.00 


Video Switcher 


5 


$100 


$500.00 


Compression Card 


3 


$300 


$900.00 


Digital I/O Card 


5 


$200 


$1000.00 


SVGAMonitor 


3 


$500 


$1500.00 


Keyboard / Mouse 


4 


$25 


$100.00 


OperatingSystem 


5 


$100 


$500.00 


Compression Libraries 


5 


$250 


$1250.00 


Web Server S/W 


5 


$250 


$1250.00 


Enclosure Prototypes 


4 


$2500 


$10000.00 


Cameras 


10 


$300 


$3000.00 


CCTVMonitor 


3 


$250 


$750.00 


Video Printer 


1 


$500 


$500.00 


LaserPrinter 


1 


$500 


$500.00 


BRANCH TOTAL 


$36600.00 
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This table breaks down the materials needed for the development of the ATM Internal DVR 









1 


MATERIAL 


QUANTITY 


PRICE 


TOTAL COST 


Removable Media 


3 


$500 


$1500.00 


Data Cartridges 


5 


$100 * 


$500.00 


LAN Card 


3 


$100 


$300.00 


Modem 


3 


$100 


$300.00 


Frame Grabber Card 


5 


$500 


$2500.00 


Web Server S/W 


5 


$500 


$2500.00 


LAN Hub 


3 


$250 


$750.00 


DIGITAL VIEWING SYSTEM TOTAL 


$8350.00 
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This table breaks down the materials needed for SQA testing. 









^^^^^ 


MATERIAL 


QUANTITY 


PRICE 


TOTAL COST 


Branch DVR 


2 


$4000 


$8000.00 


Cameras 


3 


$300 


$900.00 


CCTVMonitor 


2 


$250 


$500.00 


SQA TOTAL 


$9400.00 
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This table breaks down the contract and materials needed for regulatory testing. 







MATERIAL 


QUANTITY 


PRICE 


TOTAL COST 


Branch DVR 




$4000 


$12000.00 


UL Electrical Safety 




$2500 


$2500.00 


ULPerformance 




$5000 


$5000.00 


CSA Electrical Safety 




$2500 


$2500.00 


FCC 




$2500 


$2500.00 


CE Electrical Safety / 
Telecommunications 




$12500 


$12500.00 


REGULATORY TOTAL 


$37000.00 
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8. PHASE #1 TIME & MATERIAL 



Breakdown 


Material & 
Contract 


Labor 


Total 


Hardware Evaluation 


$39,500 


$46,000 


$85,500.00 


High Level Design & Build #1 


$5,500 


$150,000 


$155,500.00 


Build #2 & Build #3 


$0 


$192,000 


$192,000.00 


Sales Tools 


$0 


$12,000 


$12,000.00 


Branch Enclosure Design & Regulatory Testing* 


$70,000 


$5000 


$75,000.00 


SQA 


$9,500 


$27,000 


$36,500.00 


TechnicalPublications 


$0 


$23,500 


$23,500.00 


TOTAL for PHASE #1 


$124^00.00 


$455,500.00 


$580,000.00 



* - includes $33,000 for mechanical design of enclosure 
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9. SUMMARY 



Targetproducts: Branch DVRand ATM Internal DVR 



Target date: 



Target raw cost Branch DVR 



$2500.00 



ATM Internal DVR $1000.00 



Target features: 



ATM Internal DVR 



• Hardware alarm input & log file 

• Communications via dial-up or network 

• Remote software updates 

• Remote configuration and image review 

• E-mail alarms for low disk space and alarm conditions 

• Image resolution equal or better than VCR 

• Picture quality sufficient for fraud investigation 

• Image security 

• Image motion detection 

• Transaction data stored with image 

• dock synchronized with ATM 

• Removable storage 

• Remote and local diagnostics 

• Option for automatic daylight savings 

• System security 
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Branch PVR 



• Hardware alarm input & log file 

• Compression rate can vary during alarm condition 

• Communications via dial-up, direct serial connect or network 

• Remote software updates 

• Remote configuration and image review 

• E-mail alarms for low disk space and alarm conditions 

• Minimum of 4 composite video inputs 

• Image resolution equal or better than VCR 

• Picture quality sufficient for fraud investigation 

• Image security 

• Image motion detection 

• Programmablevideo output 

• Transaction data stored with image 

• Clock synchronized with ATM 

• ExpressBus and Higjh-Side comm. monitoring for 2 ATM*s 

• Removable storage 

• Remote and local diagnostics 

• Local configuration using video output 

• Option for automatic dayiigjit savings 

• System security 
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DVR Schedule 



EXHIBIT B 



ID 


Task Name 


Start 


Finish 


Hours 


Resource Names 


er 


1 


DVR Desian & Development 




10209.55h 






2 


PHASE #1 




10209.55h 






3 


BRANCH DVR 




1700h 






4 


Hardware evaluation 




520h 






5 


Power supply 




40h 


Person #1 [0.25] 




6 


Motherboard 




40h 


Person #1 [0.25] 




7 


Removable media 




40h 


Person #1(0.5] 




8 


Hard drive 




20h 


Peison #1(0.5] 




9 


Floppy drive 




20h 


Person #1 [0.5] 




10 


Digital I/O 




40h 


Person #1(0.5] 




11 


Cables 




40h 


Person #1(0.5] 




12 


Buttons, LEDs, etc. 




40h 


Person #2(0.5] 




13 


LAN card 




40h 


Person #2(0.5] 




14 


Modem 




40h 


Person #2(0.5] 




15 


RS-485card 




40h 


Person #2(0.5] 




16 


Frame Grabber 




80h 


Person #2(0.5] 




17 


Video Switcher 




40h 


Person #2(0.5] 




18 


Hardware finalization 




252h 






19 


Select hardware 




132h 


S/W #1(0.15] 




20 


Hardware documentation 




120h 


Drafting #1(0.25] 




21 


Hardware released 




Oh 






22 


Enclosure design 




544h 






23 


Enclosure concept 




192h 


Mechanldal EngineerfQ.8] 




24 


Design enclosure 




25Sh 


Meehanlcial Engineerp.S] 




25 


Prototype 




96h 


Mechanlctal Engineer(p.8] 




26 


Protype available for test 




OA 






27 


Enclosure regulatory testing 




108h 






28 


FCC testing 




24h 


S/W #5(0.05] 




29 


UUCSA testing 




24h 


S/W #5(0.05] 




30 


CE testing 




60h 


SW #5(0.1] 




31 


Regulatory testing complete 




Oh 






32 


Software component evaluation 




276h 






33 


Web server 




Oh 






34 


Database 




Oh 






35 


Image security 




Oh 






36 


Image compression 




Oh 






37 


Operating system 




Oh 






38 


Select components 




180h 


S/W #1(p.15],SfW #2(P.151,SAW #3[p.15],S/W #4[0.15],S/W #5 
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DVR Schedule 



2 



ID 






Finish 






er 


Task Name 


Start 


Hours 


Resource Names 




39 


Document components 




son 


5/W rn[0.O5j,S/W fF2[0.D5],SjW #3[0.Q5j 




40 


Software components documented 




0/j 






41 












42 


ATM (Internal) 






28Sh 






43 


Hardware evaluation 






80h 


Personal [0.25] 




44 


Hardware finalization 






126h 






45 


Select hardware 




36h 


S/W #2[0.15] 




jiff 
46 


Document hardware 




90h 


Drafting #1 [0.25] 




47 


Hardware released 




Oh 






48 


Hardware Integration 




Oh 






49 


Hardware Integration Complete 




Oh 






50 


Software component evaluation 




80h 






51 


Web server 




Oh 






52 


Database 




Oh 






53 


Select components 




48h 


S/W #3p.1lS/W #4tfX1] 




54 


Document components 




32h 


S/W #4 [0.05] 




55 


Software components documented 






Oh 






56 


Software modifications to ATM 






Oh 






57 


Software Integration 






Oh 






58 


Software Complete 






Oh 






59 


■ ■ ■ ■ ■ mm im. . . . 

lnterbold Testing 






Oh 






60 


Interbold Testing Complete 






Oh 






61 














62 


Software desian and evolution 






6259.97h 






63 


High level system design 






588h 






64 


Use cases 






Oh 






65 


Preliminary domain object model 






Oh 






66 


Design Review 






Oh 






67 


Scenarios 






Oh 






68 


Object interaction diagram 






Oh 




■ — * 


69 


State transition diagrams 






Oh 






70 


System diagram 
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To-: < Jeff Enright@ElecSecEng@Diebold 

Cc: EXHIBIT 

Bcc: 

From: Roy Hathaway@ElecSecEng@Diebold 

Subject: Status Report 

Date: 8:39:19 EDT 

Attach: 

Certify: N 
Priority : Normal 



Defer until: 
Expires : 
Forwarded by: 



WEEKLY REPORT 
Week Ending 



CAU: 

1. Completed review of first draft of the installation manual for the 
universal kit. Began review of manual for Smart and Dumb RTU. 

DVR: 

2. Had design review of the VAC board. Investigating timing issues 
on VAC board. 

3. Les has started work on ordering parts for prototypes. 30 sets of 
parts will be ordered. 

4. Received lay-out of VIA board. VIA board had a few mistakes, but 
overall looked pretty good. 

5. We are approximately 1 to 1 1/2 weeks behind schedule. The 
designer at Merriwether is out of town Friday and Monday so two 
days will be lost. Merriwether has stated we may have VIA boards 
on the 14th and possibly VAC boards on the 17th. 

NIA: 

6. Received another call from Randy Mauldin regarding PROMs for First 
American. Chuck Devore will handle this problem. 

MST: 

7. Received a CVQ for another source for PAL used on ST, ESP and 
Comm Processor board. Jeff Adams will investigate. 



Roy 
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1. PURPOSE 



This specification outlines the features and functionality for the Branch version of the Diebold Digital 
Video Recorder (DVR) family. 



2. SCOPE 



This document will define the functionality of the Branch version of the DVR This document will 
include the potential features and functions, the system interfaces, and any performance requirements. 
This document will not attempt to outline the implementation or phasing of the features described 
within. 



3. PRODUCT DEFINITION 



The Branch DVR is a digital replacement for the Diebold analog video surveillance systems. The digital 
capture and storage of images will provide a flexible and reliable means of capturing surveillance 
events. The Branch DVR will be capable of monitoring ATM, branch and limited alarm activity. The 
Branch DVR software system will include web server software, which will provide a convenient means 
of remote communication to the DVR, as well as a consistent and easy to use user interface. The Branch 
DVR will store images on removable digital media, allowing the images to be viewed on a remote 
computer running web browser software. The Branch DVR will be fully programmable either locally or 
remotely via a remote computer running web browser software (See Figure 1). 





Computer Running Web Browser 
Software For Remote Viewing of Images 
and Remote Programming of DVR 



InterBold 
ExpressBus 



OR 



Hi-side Network 
Communications 



Figure 1 
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4. SYSTEM INTERFACES 



4.1. HUMAN 

The human interface will consist of an intuitive combination of controls and indicators that will 
reside either on the front panel of the DVR or through the web browser interface. At a 
minimum the following controls/indicators will be provided: 

Question: 

An intuitive combination of controls and indicators that will reside either on the front 
panel of the DVR or through the web browser interface. — How intuitive will be and how 
can SQA test those functions in SQA lab? What devices (in the figure 1) will we use in the 
DVR test? 



Power indicator 

"Happy-light" 

Disk Status 

Online/Communicating 

Record/Capture 

Eject 

Stop 

Play 



The Branch DVR will also be equipped with a web based user interface via web browser 
software (e.g. Netscape Navigator). This will allow DVR programming and reviewing of 
images both locally (See Figure 2) and remotely on a networked computer (See figure 1). 

Question: 

What is the meaning of DVR programming of images locally and remotely? How can we 
test it? 
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Operator will have access to Web Browser 
software locally, for local viewing, and 
programming of DVR. 

The video output can be viewed via 
CCTV monitor or VGA monitor. 





CCTV Monitor 
or 

VGA Monitor 



The DVR front panel will contain 
various LEDs to indicate DVR 
functions (I.e. capture.reverse, 
forward, etc.) 



Mouse Input will be used 
for easy navigation around 
DVR programming menus 
and viewing options 



Figure 2 

The Branch DVR will have multilingual support. The initial release of the DVR will be limited 
to English. Future releases of the DVR may be available in one or more of the following 
languages: Latin Spanish, French, German, Italian, Portuguese, Arabic, Russian and Chinese. 

The Branch DVR will have online help and instructions available on the display, to aid in 
setting up and operating the system. 



4.2. MECHANICAL 

The Branch DVR will have a custom enclosure that is capable of housing PC compatible 
components. The DVR will be at the most, the size of current CCTV analog VCR decks. The 
enclosure will have flexible internal mounting brackets for removable media devices as well as 
future internal expansion. 

4.3. ELECTRICAL 

The Branch DVR will be 110/220 VAC 50/60Hz compatible. The Branch DVR will conform 
to UL Safely 1950 and CSA 950. 

Question: 

How can we conform those in DVR? 

4.4. NETWORK 

The Branch DVR will have a scaleable network interface allowing the unit to communicate 
over several network topologies. The interface will be scaleable via internal communications 
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cards as well as external adapters when necessary. The Branch DVR will need, at a minimum, 
interfaces to the following networks: 







ExpressBus 


RS485 


Dial Up 


Public Switched Telephone Network 




(PSTN) Modem 




ISDN 


Serial Network Connectivity 


RS232 


LAN connectivity 


Token Ring, 10 Megabit Ethernet 


Hi-side Monitoring 


RS232, LAN 



Question: 

The network topologies and the minimum interfaces need more explanations for us* 
Do we use Low-side ? 

4.5. SOFTWARE 

The Branch DVR will utilize off-the-shelf software "parts" when appropriate. This will speed 
development time and allow the development to be concentrated on the application specific 
sections of the software. Some of the software components that will be purchased, but not 
limited to, are as follows: 

Question: 

Can SQA have some more explanations about Network Protocols ( Asynch. & Synch)? 



Web Server Software 

Web Browser Software 

32 bit Operating System 

SQL Database Management 

Networking Protocols (IP, Asynchronous, 
Synchronous protocols) 
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5. FEATURES 



This section describes, in detail, the hardware and software features of the Branch Digital Video 
Recorder. 

5,1. HARDWARE 



5.1.1. VIDEO INPUTS/SWITCHING 

A minimum of 4 composite inputs will be provided, via a software controlled video switcher. 
Video inputs can be added in increments between 4 and 8. This may be either an internal card 
(ISA or PCI) or an external video switcher controlled via a serial port The option of either 
EIA/NTSC or CCIR/PAL inputs will be provided. p 

Questions: ^ c _ _ _ / 




What are the composite inputs definition? 
What is the Maximum of the composite inputs? 
What is Software Controlled Video Switcher? 
We need some more explanations for the following description 

Video inputs can be added in increments between 4 and 8 . "This may be either an internal 
card (ISA or PCD or an external video switcher controlled via a serial port . The option of 
either EIA/NTSC or CCIR/PAL inputs will be provided. 
What are the definitions for EIA/NTSC and CCIR/PAL? 



5.1.2. VIDEO OUTPUTS 

At a minimum one composite video output will be provided. This will allow the connection of 
an optional analog CCTV monitor. An optional bridging monitor output will also be provided. 

Questions: 

What is the maximum of the composite video outputs? 

What is the optional analog CCTV monitor and what is the optional bridging monitor 
output? 



5.1.3. IMAGE PRINTING 

The DVR will have the ability to print images locally via a PC compatible printer port. The 
DVR will take advantage of the operating systems print services for this function. System 
compatible printers will be evaluated and specified. Printers will be selected based on system 
compatibility, cost and quality of the printed image. 

The DVR will have the ability to be connected to a CCTV video printer. This will more than 
likely be a connection to the video output port, allowing the displayed images to be printed. 

Questions: 
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The DVR will have the ability to print images locally via a PC compatible printer port. -Does 
this sentence talk about the port - LPT1? 

System compatible printers will be evaluated and specified. - How many printers will be used 
in SQA testing? Are they all color printers? 

What is the CCTV video printer? 



5.1.4. SYSTEM PLATFORM 

The system platform will be a PC compatible platform, with the capability of running a 32 bit 
operating system. The following minimum system requirements will allow adequate 
performance of a 32 bit operating system along with the multimedia requirements of the system: 

• Pentium 100 motherboard 

• 32 Mb RAM 

• 2 Gigabyte hard drive 

• 3 ISA; 3 PCI and 1 shared ISA/PCI 

Questions: 

What are the multimedia requirements? 



5.1.5. VIDEO FRAME GRABBER 

The DVR will be equipped with a minimum of one video frame grabber. This will be at a 
miTnmnm an ISA compatible card, but a PCI based card will provide the maximum 
performance. 
Questions: 

What is the maximum of the video frame grabbers? 
How many will be tested in SQA lab? 

Which Card will be use for the SQA testing ISA compatible or PCI? 

What does The video frame grabber will be capable of a minimum of a 20 frames per second 

(fps) capture rate really mean? 

How can SQA check the rate 20f/s and how can we compare with a full motion video? 



The video frame grabber will be capable of a minimum of a 20 frames per second (fps) capture 
rate, which is comparable to full motion video. 



5.1.6. HARDWARE IMAGE COMPRESSION 

For performance critical applications, hardware image compression will be used. This will 
come in the form of a separate ISA or PCI based card, or if available, an integrated part of the 
frame grabber card. 




Questions: ' " w ' * ' ' 



We need more explanations about this function! Y * 

What does hardware image compression will be used really mean? 

Which one will be in using from those options -This will come in tt/e form of a separate ISA 
or PCI based card, or if available, an integrated part of the frame grabber card? 
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5.1.7. ALARM INPUTS 



The DVR will have a minimum of 4 alarm inputs. The alarm inputs will be internal to the 
Branch DVR. 

Support for ATM panic button applications will be provided as alarm inputs as well. 
Questions: 

What is the maximum alarm inputs? 

What are the categories defined for those alarms? 

What does The alarm inputs will be internal to the Branch DVR mean? 

How can we test this - Support for ATM panic button applications will be provided as alarm 

inputs as well in SQA lab? Do we need the devices? 

5.1.8. ALARM OUTPUTS 

The Branch DVR will have a mmimnm of 4 alarm outputs. The alarm outputs will be internal 
to the Branch DVR. 

Questions: 

Do we have the maximum for alarm outputs? 

What does this — The alarm outputs will be internal to the Branch DVR really mean? How 
do we test the function? 

5.1.9. DATA STORAGE DEVICES 

The DVR will contain an internal hard drive for system files, logs and image caching. A 
removable data drive (e.g. ZIP drive, JAZ drive), will also be provided for all image storage and 
archiving. The removable drive will either be an IDE or SCSI compatible device mounted 
internal to the DVR enclosure. 

Questions: 

How many are "All" images? 

SQA will test "JAZ full" and "JAZ not inserted"? 

The DVR will have a 3 Vi floppy drive on the front of the unit, for DVR programming input, 
boot recovery and software updates. No image data will be stored on this device, it will only be 
used as a service tool. 

5.1.10. COMMUTATIONS 

The Branch DVR will be equipped with several communications interfaces. These will allow 
direct communication with a remote viewing station, eavesdropping on ATM Lo-srde and Hi- 
side communications and interface to the Teller line communications. The following are 
minimum interface requirements for a Branch DVR system: 

Questions: 
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What are those communications' definitions of direct communication with a remote viewing 
station, eavesdropping on ATM Lo-side and Hi-side communications and interface to the Teller 
line communications? 



Which one is being tested in SQA lab Lo-side? Or Hi-side? Lo-side is not mentioned in 
section 4.4 — Network. 

How can we test them in SQA lab? 



• Public Switched Telephone Network (PSTN) Modem 

A PSTN modem will allow dial up communications between the Branch DVR and a 
remote viewing station. At a minimum the modem will be a 28.8 KBPS Hayes 
compatible internal modem. If an internal modem is not feasible (space constraints), 
an equivalent external version of the modem will be used. 

• Token Ring or 10 Mb Ethernet Network Interface Card (NIC) 

An internal NIC will be provided where advanced protocols (TCP/IP) will be used to 
communicate to a remote viewing station, or to eavesdrop on an AIM'S Hi-side 
communications network. At a minimum, the card will be ISA compliant 



• RS485 Interfaces 

The Branch DVR will have anywhere from 0 to 4 RS485 interfaces to allow the DVR 
to eavesdrop on the ExpressBus of up to 4 ATM's. This interface will be in the form 
of an internal ISA compatible card. The RS485 interfaces will only be used for 
eavesdropping, and will not have the ability to drive the line at all This will provide |£iA- 
some protection against "locking-up" the ATM's ExpressBus. 

Questions: ^ 
How can we test this functions with 4 ATMs in SQA lab? Can we simulated the 
network traffic (like we do in D5100D sim test)? 

How can we test this function — The RS485 interfaces will only be used for 
eavesdropping, and will not have the ability to drive the line at all. This will provide 
some protection against w locking-up" the ATM's ExpressBus ? 
Do we have to setup the test system with different communication interfaces? J 



• RS232 interfaces 

The Branch DVR will have at a minimum l RS232 interfaces and up to 5 depending 
on the application. The RS232 interfaces will allow remote connectivity to a remote 
viewing station, as well as provide an eavesdropping interface for up to four ATM's 
and an interface to Teller lines. The RS232 eavesdropping interfaces will allow the 



Questions: 

Can we have more explanations of this NIC function? 
Do we need to test this function in SQA lab? 
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Branch DVR to monitor the ATM's Hi-side communications for transaction 
information. 

5.1.11. INDICATORS 

The front panel of the DVR will have a two visual indicators to give feedback as to the status of 
system functions. 

5.1.11.1. Hardware Indicators 

• Power 

The Power indicator will be illuminated when the DVR power is normal. 

5.1.11.2. Software Controlled Indicators 

• Happy Light 

The Happy Light will give a quick indication as to system status. When the 
happy light is illuminated, the system is functioning satisfactorily. When the 
happy light is o£^ there is a problem with the DVR, which can be determined 
by running a diagnostic check on the system and viewing the system status on 
the DVR's display. 

Questions: 

Is this — a diagnostic check on the system and viewing the system status on 
the DVR's display a software tool? 

• Capture Indicator 

The Capture Indicator will be illuminated when the DVR is capturing an 
image and saving it to disk. 

• Disk Status 

The Disk Status indicator will visually inform the operator/user when the 
removable media is approaching full (e.g. 80% full), or when the disk is at 
maximum capacity. 

Questions: 

Which one is the final definition for Disk Status - when the removable 
media is approaching full (e.g. 80% full), or when the disk is at maximum 
capacity ? 

What is the near full condition (see below description)? 

How is the disk status mapped to an alarm output? 

Does the DVR system annunciates this condition by E-mail? 

Disk status can also be mapped to an alarm output to annunciate either a full 
or near full condition. 
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The warning threshold for a disk low warning will be programmable from a 
minimum of 50% full to 95% full- 
Questions: 

Is 95% required to give the message? 

Can we have some more explanation of the word 'programmable'? 
• Online 

The Online indicator will be illuminated when the Branch DVR is 
communicating with a remote viewing station. 

5.1.12. SCALEABILITY/MODULARITY 

The use of a PC compatible architecture will allow for flexible expansion of the DVR system. 
Expansion will be internal to the enclosure when feasible (not including cameras) , however, for 

Why? 

larger systems it may be necessary to bring some expansion hardware out of the enclosure (i.e. 
switchers, removable data devices, etc.). 

The DVR will be designed for maYimiiTn modularity. This will allow the system to be 
configured anywhere from a low-end (e.g. 4 video inputs, 4 alarm inputs, standalone), to a fully 
equipped Branch DVR (e.g. 23 video inputs, 8 alarm inputs, etc.), by use of expansion modules 
(in this case either additional PC cards, or external devices). 

Questions: 

How is the DVR system configured from a low-end .... To a fully equipped Branch DVR? 
Why 4 video inputs, 4 alarm inputs, standalone? 
Why 23 video inputs, 8 alarm inputs, etc. ? 

5.1.13. AUDIO 

Optional Audio input capability will be provided by a PC compatible sound card (e.g. 
SoundBlaster). The audio function will be tied in with the image capture such that there is 
correlation with the captured images and the audio "track". 

Questions: 

What is the 'optional' mean here? 

Does SQA need a SoundBlaster to test this function? 

5.1.14. ENCLOSURE 

The enclosure will be custom made and "non-PC" in appearance. The enclosure will house all 
the PC components where applicable. All indicators and controls will be located and clearly 
labeled on the front of the enclosure. Any connectors and external interfaces will be on the 
back of the unit 

The enclosure will have a footprint similar to that of analog VCR decks. 
Questions: 

What does this - a footprint similar to that of analog VCR decks mean? 
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5.1.15. DIGITAL CAMERAS 



Digital Cameras will be specified when the PC interface and cost are feasible. Digital Cameras 
will eliminate the need for a frame capture card, but may require a separate interface card for 
the camera. 
Questions: 

Do we really use Digital Cameras in current Branch DVR system? If not, When the PC 
interface and cost are feasible? How will SQA setup the test system? 

5.2. SOFTWARE 

5.2.1. IMAGE CAPTURE 

Digital images will be captured and processed locally. Processing will consist of compression, 
embedding of image security, linking of transaction or alarm data, and storage in a local 
database. 

Questions: 

Do we have interfaces or background tables or commands to test those 4 functions — 
compression, embedding, linking and storage? What kind of Software do we use for 
execution? 

Can we have more explanation of the function — Picture quality adjustments, such as 
brightness, contrast, etc. will be programmable (on a camera by camera basis) ? What about 
Sharpness ? 

Image data will be stored along with the image, not embedded into the image. This will allow 
for higher compression ratios, as well as better data integrity. 

Picture quality adjustments, such as brightness, contrast, etc. will be programmable (on a 
camera by camera basis). 

5.2.2. IMAGE STORAGE/ARCHIVING 

The captured images and data will be stored on the removable media as records in a database. 

When a data cartridge is being replaced, the image data will be temporarily stored on the 
internal hard drive. Once the cartridge is replaced the images will be transferred to the 
removable cartridge. 

Questions: 

This will be a system stress test with 20 frames/second capture rate. What will happen if 
we will stress the Branch DVR system? 

5.2.3. IMAGE SECURITY 

Each image will be secured such that image tampering can be determined. The image security 
will not prevent the image from being viewed, just from being modified. The image security 
field is still pretty immature; therefore the software will be designed such that new image 
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security technologies can be easily integrated into the system. The following image security 
technologies are being considered: 

• Digital watermark 

• Digital signature 

• Digital envelope/seal 

The goal will be to utilize a security technology that is least invasive to the image, yet provides 
an ample amount of security. 

Questions: 

How can we test that image tampering can be determined ? 

What image security technology are we using now in the DVR system? 

5.2.4. SOFTWARE IMAGE COMPRESSION 

Software image compression will be used in situations where hardware based compression is 
not required to meet performance needs. Software compression libraries will be purchased, and 
the software will be designed to allow easy integration of new compression technologies as they 
are developed. The following image compression technologies are being investigated. One will 
be integrated into the DVR system: 

• Wavelet - commercial libraries available 

• JPEG - public domain algorithms available 

• Fractal - commercial libraries available 

These are all lossy compression technologies (Image quality is reduced with higher compression 
ratios), however to provide an efficient form of image archive and storage this will be necessary. 
JPEG provides somewhat of an industry "standard", however wavelet technology provides much 
higher compression ratios with less loss than JPEG or Fractal. 

Questions: 

Can we have more explanation of that Software image compression will be used in situations 

where hardware based compression is not required to meet performance needs ? 

Which image compression technology are we using in DVR system? JPEG or Wavelet? 

5.2.5. PROGRAMMING/SURVEILLANCE SCHEDULING 

The Branch DVR will have flexible programming to allow setting of various system functions 
and operations. The DVR will have the ability to be programmed locally as well as remotely 
via a remote viewing station. This section will detail the programming and surveillance 
functions of the Branch DVR. 

Questions: 

How do we test the local and remote programming ability ? 

Where can we find or get those data as following mentioned to set up SQA test system? 
What are the settings for Communications settings and ATM interface settings? 
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Does SQA need to order or setup a simulated or real ATM interface for the DVR testing? 



• Communications settings (Lo-side, Hi-side, remote viewing station) 

• baud rate 

• telephone numbers (up to 10) 

• data bits 

• stop bits 

• parity 

• Synchronous, Asynchronous 

• RTS, CTS, DCE, DTE settings 

• Communications port (i.e. coml, com2) 

• ASCII/EBCDIC 

• TCP/IP settings 

• ATM interface settings 

• ATM ID/address 

• Message Formats 

• Diebold 911/912 

• NCR Native 

• BM473X 

• ExpressBus 

• Transaction Capture setup 

• Card Data 

• Account info 

• Devices on which to capture 

• ATM Network Protocols 

• SDLC 

• TC500 

• IBM 3275 

• Express Bus 

• Camera Sequencing (normal sequencing) 

• Camera by Camera setup 

• Up to 23 cameras in sequence 

• Camera can be "on" for a number of frames or amount of time 

• Camera programmed for up to 10 consecutive frames. 

• Camera programmed for up to 10 seconds of capture. 

• Camera can be placed anywhere within sequence, and multiple times within 
sequence. 

Questions: 

How many cameras do SQA need to test the DVR system according to the description « 
"Camera by Camera setup", and "Up to 23 cameras in sequence? 
How does the 20 frames/second capture rate relate to 
Camera programmed for up to 10 consecutive frames, 
Camera programmed for up to 10 seconds of capture? 

"Camera can be placed anywhere within sequence, and multiple times within sequence" Any 
standards for the sequence and multiple times ? 

• Alarm Sequencing 

• Unique Sequencing per alarm input (hard or soft alarms) 
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• Up to 23 cameras in sequence 

• Camera can be "on" for a number of frames or amount of time 

• Camera programmed for up to 10 consecutive frames. 

• Camera programmed for up to 10 seconds of capture. 

• Camera can be placed anywhere within sequence, . and multiple times within 
sequence 

• Maintain sequence for duration of alarm contact, or set amount of time 

• Programmable number of saved images both pre and post alarm 



Questions: 

Will each camera action be an Alarm? 

Can we have more explanation of Maintain sequence for duration of alarm contact, or set amount 

of time and Programmable number of saved images both pre and post alarm? 

What is the limit for the programmable number of saved images both pre and post alarm? 



• Sequencing Schedules 

• Maximum of 7 time schedules per day How is this defined ? 

• Auto Daylight savings time adjustments What does this mean ? 

• Schedule ID's Number? Name? Or Both? 

• Camera ID's Definition ? 

• By default camera will be identified by it's video input number 
How is the video input number defined ? 

• Can give each camera a unique name up to 32 characters 

• Camera identified by number, name or both 

• Duplicate name check 

• Camera can be referenced by name or number 



• Motion Detection settings 

• Programmable detection zone 

• sensitivity settings (high to low sensitivity) 

Questions: 

What is the definition of Sensitivity settings ? Brightness? Move speed? 
Sharpness? 

How can we check the programmable detection zone? 

• Date/Time setup 

• Auto daylight savings time adjustments (programmable on/off) 

• Date format 

• MM-DD-YY 

• DD-MM-YY 

• Time Format 

• 12 hour 

• 24 hour 

• "Lock" on ATM's time/date 



Questions: 

Do we use *00* to indicate Year 2000 or not ? 

What does "Lock" on ATM's time/date really mean to SQA test ? 
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Do we have the Audio input to test in SQA lab? 



• Audio Setup 

• One camera linked to audio input 

• Capture audio on alarm sequencing 

• Capture audio during normal sequencing 

• Operator enrollment 

• Operator name 

• Operator password 

• Operator privileges 



Image compression "ratios" 
• Maximum quality vs. Maximum storage 



Lower compression ratios for alarm sequencing 



What is this mean and what 
is the limit? 

What is the definition of 
Lower Compression ratios? 
Programmable on a camera by camera basis for both alarm and normal sequencing 

What will happen if use 
abnormal sequencing? 



Video output 
video 

• Single camera output 

• Follow sequencing of cameras 

• Follow alarm sequencing 

Image Storage and Archiving 

• Automatic data overwrite/deletion 



• By date 

• By number of images 

• By event 
related 

• By camera 

• Log File archiving functions 

• Ability for alarm events to overwrite 
so that f>1 arm events cannot be lost 

• Log file overwrite/deletion functions 

• Image/Data deletion protection 

• By expiration date 

• By event 

• By camera 



Where can view the 
output ? 

What will happen if not 
follow those sequencing ? 

How many days or hours 
images can be stored or 
archived before overwrite 
or deletion ? 

Are there priorities 
Events ? 



other events, except events of equal priority, 
What are other events and 
what does equal priority mean? 
What is the conditions for 
overwrite/deletion functions? 



Local Configuration 

• Interface to DVR menus through local web browser Talk about online help? 
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♦ Ability to copy programming data to disk 



What is programming data? 



• Pre-programmed "scripts" What are Pre-programmed 

"scripts"? How can we test 
them ? 

Pre-programmed scripts or DVR programs will be available locally for typical 
surveillance applications (i.e. convenience stores, ATM vestibules). The scripts will be 
based on typical hardware configurations, and can be customized to the application. 

Need more explanation of this 

function; 

• Automatic archiving of DVR programming data Need more explanation; 

The DVR will have the ability to "save-ofl" its programming data to removable media 
each time the cartridge is replaced. This will act as an automatic backup of the 
system's programming in the event the DVR becomes inoperable and needs 
replacement or the programming data becomes corrupted. 



• Download of programming data from remote viewing station 

All programming data can be downloaded to a Branch DVR from a remote viewing 
station. The download of the data will be initiated by the remote viewing station. Data 
integrity checks will ensure that the data arrived intact and programming of the DVR 
was successful. 

Questions: 

What kind of software tool does the Data integrity checks mean? 
Do we need to send some "bad data" to test this function? 
How many Branch DVRs will need to be setup for SQA test? 

• Download of programming data from DVR floppy drive 

The Branch DVR programming can be copied or "downloaded" from the 3 Vz floppy 
drive on the unit The source of this programming can either be from the remote 
viewing station or another DVR This will allow quick programming of DVR units 
with common programming. 



5.2.6. ALARMS 



Both hard and soft alarm inputs will be used to trigger image capture. Hard alarms will come 
from an alarm I/O card or external trigger source. Soft alarms may come from, but are not 
limited to : 



• Video motion detection, 

• "Hof card detection 

• Loss of video detection 

• Black level detection (i.e. camera covered with hand) 
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Programmable compression ratios for alarm events will allow improved image quality during 
alarm situations. The number of frames saved before and after alarm events will also be a 
programmable feature. 

All alarm data will be logged to a separate log file. The following data will be saved as part of 
an alarm event: 



• Date/Time 

• Alarm source 

• Transaction information (if available) 

• Captured Image file name 

• Alarm Type 

• Location 



The Branch DVR will have the ability to annunciate alarm conditions to remote computers via 
E-mail. 

Questions: 

What is an alarm I/O card or external trigger source ? 

We need explanation of the following functions: Video motion detection, "Hot" card 
detection, Loss of video detection and Black level detection (i.e. camera covered with hand). 
How can we test them? 

What is that Programmable compression ratios for alarm events will allow improved image 
quality during alarm situations. The number of frames saved before and after alarm events will 
also be a programmable feature mean ? 

What is the range of The number of frames saved before and after alarm events ? 



5.2.7. DIAGNOSTICS 

The DVR will maintain a series of diagnostic log files to aid in servicing the system. The 
following are some of the log files that will be generated. 

• Boot data What is "Boot Data"? 

• Disk status 

• Power What should we look for? 

• Error Status How can we do System Error Check test? 

The log files will be viewable locally via the CCTV monitor, as well as remotely via a remote 
viewing station. 

The DVR will be in a constant "self diagnostic" mode to detect any system errors and problems. 
Any status changes will be reported on the front panel of the DVR and, if installed, a monitor 
connected to the DVR System problems will also have the ability to be reported to a remote 
viewing station. The following are some of the diagnostic functions that will be monitored: 

• Disk level diagnostics 

• PC based diagnostics (memory, I/O) 

• Communications diagnostics 

• Frame grabber diagnostics 

• Removable media diagnostics 

• Video diagnostics 
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• Print diagnostics 

• Software subsystem diagnostics, such as database corruption, etc. 
Questions: 

How do we check all those system problems? 

What the following function really mean and how does SQA test it ? 

There will be a "one-button 9 * access to the DVR diagnostics giving an easy means of accessing 
more common system statuses. 

The Branch DVR will have the ability to annunciate diagnostic information via E-mail to 
remote computers and users. 

5.2.8. REMOTE COMMUNICATIONS 

The Branch DVR will have the capability to communicate remotely with a computer running 
web browser software, such as Netscape Navigator or Microsoft Internet Explorer. This will 
allow the control of many operational and support functions of the Branch DVR. These 
functions will include: 

• Transmission of images and data 

• Software updates to the DVR 

• Downloading of programming data 

• Diagnostic access/remote control 
Questions: 

What is Diagnostic access/remote control ? 

The DVR will have the capability of connecting to the remote viewing station either via direct 
communications (RS232, LAN), or via dial-up connections, depending on the application. 
Which one will be used in the test? 

The level of communication between the DVR and the remote viewing station will be 
programmable. This will include set up of "Batch" transmission of images and data in off-peak 
hours, unsolicited transmission of images and data upon the occurrence of events (e.g. alarms), 
and the remote storage/archiving of DVR images and data. 

The DVR will have the ability to send "live" video streams to the remote viewing station upon 
request The quality of the video will be dependent upon the communications connection being 
used. 

What does '"live" video streams' mean and how do we generate the streams? 
What communication connection will be used in DVR team or SQA? 
What is DES and what is PGP? 

The connection between the Branch DVR and the remote viewing station will utilize some 
form of line security (e.g. DES, PGP), to discourage eavesdropping or line substitution. 

5.2.9. DATABASE 

The captured images and data will be maintained in an SQL (Structured Query Language) 
database. This database will be a 3 rd party off-the-shelf software package that has the ability to 
handle complex data types, like images. 
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What is the software 3 rd party off-the-shelf software package that has the ability to handle 
complex data types, like images. ?? 

The interface to the database will be designed to allow easy integration of various database 
engines, for maximum flexibility. The interface will also be designed to allow the easy 
integration of additional database fields. 

What is the interface "The interface to the database will be designed to allow easy integration 
of various database engines, for maximum flexibility. The interface will also be designed to 
allow the easy integration of additional database fields" ?? How can we test this?? 



5.2.10. ATM SOFTWARE INTERFACE 



When interfaced to an InterBold ATM the DVR will make use of the ExpressBus interface to 
trigger image capture. The DVR will eavesdrop on the ExpressBus, and will not be an active 
device on the line. The DVR will monitor data from the card reader, depositor, dispenser, 
journal printer and consumer printer. The following is some of the data that can be captured 
and stored with the images: 

Questions: 

What is ExpressBus interface?? 

What does this "The DVR will eavesdrop on the ExpressBus, and will not be an active device 

on the line" mean? 

What is Hot card information? 

Need more information about ATM as following described. 

• Time and Date 

• Transaction Number 

• Hot card information 

• Location Information 

• Account Number 

• Amount of bills dispensed 

In non-InterBold applications or in situations where the ExpressBus is unable to be used, an 
interface to the Hi-side communications will be utilized Diebold 911/912, NCR Native and 
IBM 473x message formats will be supported to trigger image capture. Support for several of 
the ATM network protocols will be supported as well. This will include: 

• Async 

• BiSync 

• SDLC What does this stand for? 

The DVR will have the ability to "auto-configure" itself to the Hi-side and Lo-side 
communication settings (i.e. baud rate, data bits, etc.). The DVR will have the ability to 
manually configure the ATM network communication parameters as well. 

The DVR will be designed to allow for integration of new Hi-side as well as Lo-side interfaces 
and protocols, as ATM architecture changes. What does this mean?? 
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5.2.11. IMAGE MOTION DETECTION 



Image motion detection will be provided via software algorithms. A programmable motion 
"zone" will be provided to only detect motion in relevant areas on the image. The sensitivity 
level of the motion detection will also be a programmable item. 
What are the relevant areas on the image? 
How do you define the sensitivity level?? 

5.2.12. SECURITY 

The DVR will have a number of security measures built into it to restrict access to only 
authorized users/operators. The DVR will have a finite number of operators/users that can be 
programmed into the system. The following are some of the security measures that will be 
used: 

• Password protection 

The DVR will have operator login id's unique to each operator, administrator and 
service person User passwords will be entered from the DVR's GUI. Up to 25 
operators can be programmed into the DVR system. 

• Operator privileges 

Every valid operator on the Branch DVR will have a finite number of "privileges" that 
will give the operator access to only the functions that have been programmed for 
them. Every Branch DVR will have one "super-user" that has all privileges and can 
assign all privileges. The following are some of the programmable privileges that will 
be included in the Branch DVR 

• Operator programming/enrollment What does this mean?? 

• File deletion cartridge re-use. How can we test this 

function?? 

• Image viewing 

• cartridge replacement 

• DVR programming (schedules, alarms, etc.). 

• Diagnostic functions 

• DVR security programming 

• DVR service Can we have Explanation 

• Communications settings 



5.2.13. PLAYBACK/REVIEW 

The Branch DVR will be capable of a full selection of playback and review capabilities. The 
images and data will be viewable on a CCTV or VGA monitor attached to the Branch DVR or 
through the web interface and remote computer. The Branch DVR will have the ability to 
sequentially display the stored images, either one image at a time, slow forward, fast forward, 
slow reverse and fast reverse. The Branch DVR will also have a selection of rapid search and 
retrieval functions at its disposal. The following are features of the DVR's playback and review 
capabilities: 

• Single camera playback/multiple camera playback 
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The operator will be able to select the camera in which to view stored images, or the 
operator can sequence through the images of all the cameras. 

• "Looped" playback Can we have more explanation of "looped" ? 
A series of images can be continuously played back or "looped" for the user. 

• Thumbnail images 

All images captured by the Branch DVR can be displayed in thumbnail format. This 
will enable more images to be viewed at one time. The user will be able to click on 
any of the thumbnails to view them in more detail. User-specified criteria will also be 
available to limit the number of thumbnail images displayed at one time. 

• Manual Record Functionality 

How do we test the manual record functionality? 

From a remote computer, a user will be able to direct the Branch DVR to begin 
capturing images. Capturing will be done according to either default or user-specified 
criteria (camera sequencing, capture rate, etc.). Capturing can begin immediately or 
delayed (for a programmable amount of time or time of day). Similarly, image capture 
will end at either a specified time of date, length of time, or upon a user-specified 
command. Additionally, an authorized user will have the ability to designate whether 
alarm/event image capturing overrides the manual recording or vice versa. 

• Image Enhancements 

A user at a remote computer will have the ability to perform various image 
enhancements on the captured images. Adjustments for brightness, contrast, hue, 
sharpness, etc. will be included The ability to "zoom-in" and "zoom-out" on areas of 
an image will also be included. More advanced features, such as edge 
detection/enhancement, image smoothing, histogram equalization, etc., will also be 
available. This may be accomplished with an optional 3 rd party software package. 

How do we test those advanced features edge detection/enhancement, image 

smoothing, histogram equalization and etc.? 

What is the software of "an optional 3 rd party software package" ?? 

• Pertinent image data 

What is PERTINENT IMAGE DATA? 
How do we test the function? 

Any pertinent image data will be displayed along with the stored images. The data 
displayed and the format of the data will be programmable. Some of this data will 
include: 

• Time/Date stamp 

• Transaction data 

• Camera Number/Name 

• Account data 
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EXHIBIT E 



INTER-OFFICE MEMO 



To: Distribution 
From: Jeff Enright 



Subject: Digital Video Monthly Status Meeting - 
Purpose: 

The purpose of this meeting was to organize a cohesive Project Team to help 
bring the formcoming DVR Product to Market. This was the first time the entire 
Project Team was to be given a Demo of the actual Product. 

Intro: 

Kevin began the meeting with organizational details. Minutes will be rotated 
with Jeff volunteering for this first meeting of . Future meetings will be the 
Third Monday of the month at 8:30 a.m. in Canton Conference Room SPG #3. 

Review Overall Development: 

Mike and Jeff explained how the Project was going with emphasis on the 
critical Bank of Hawaii Demo to be conducted on It stated that all 

Hardware was going quite well and most Software was on schedule with a challenge 
area being the Operator Interface. 

Selection of Names: 

Mark Radke provided a list of potential Product names and asked for 
feedback on these candidates by " ' Mark will summarize and 

report at next meeting. We will be naming both the overall product and also one 
specific feature which will detect loss of "good " video. 



Partnerships for Customer Feedback: 

Kevin explained that we have 5 potential Customers who may agree to 
participate as a partner with us testing Alpha units. These Alpha units would have 
very limited SQA and could be modified in the field with very little inertia. The 
purpose of these units would be to allow rapid deployment of changes required 
based upon these early experience users. This needs to be managed very carefully to 
assure that features added are truly needed for the product and not just to satisfy one 
customer's fancy. 



The first Alpha site will most likely be Bank of Hawaii in the end of 
timeframe. 
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Demonstration of Software Product 



Mike Russell led a very informative demo of the actual DVR Product image 
retrieval capability via the Image Search function. This provided a very good 
foundation to all Project Team members to assure a common vision of this product 
as we prepare to release and launch. 

The system topology as well as the utilization of web browser concepts was 
conveyed to all attendees. 

Several very good questions and suggestions came out of this interactive 
demonstration. 

Lab Tour and Hardware Demo 

Jeff led the Team through the Engineering development labs and showed all 
DVR hardware progress to date. Much time was spent explaining the functions of 
the two internally developed VIA and VAC boards. Again several very good 
questions and suggestions came from this interaction. 

Forward Development Plan 

Kevin led a recap of the Product development to date and stressed that much 
has to be accomplished by this team in the next few months ahead. It was mentioned 
we are still on schedule for a Product by the end of Second Quarter. 



Next Meeting 

The next meeting is 



Thanks for your participation and interest, 



JeffEnright 



Canton, Ohio 



Mr. Ralph Jocke 
Water & Jocke 
23 1 South Broadway 
Medina, Ohio 44256-2601 

ATTORNEY-CLIENT COMMUNICATION / PRIVILEGED AND CONFIDENTIAL 



SUBJECT: AccuTrack Patent Interest 
REF: Patent Investigation Meeting 



Dear Ralph: 

Attached are the overheads used at our meeting describing our Digital Video Recorder 

(DVR) development hereafter referred to as AccuTrack. This provides a functional block diagram of the 
various portions of the AccuTrack Product. 

As a result of our meeting and much subsequent discussion, we would like to pursue patents for the 
following: 

■ Remote Access to Acquired Images - This is done via any IP network. Our current focus is 
Intranets, but we must protect Internet access as well. Optional Dial-up capability is also 
provided. 

■ Internet/Intranet DVR Appliance 

■ Non-Proprietary Retrieval Device - Our remote search capability is performed by any Internet 
capable client running industry standard Internet browser Software. 

■ Security Access - Currently we are relatively simple Password based. This may need to 
become more sophisticated and at that point might be patentable. 

■ E-Mail Alarm Messaging with associated logic which allows the user to filter which exact 
types of alarms should transmit E-mail. 

■ Alarm Triggering - We have a multitude of ways to trigger an image capture sequence. The 
method and associated logic to detect hardware alarms, motion alarms, non-useable video 
alarms, transaction based alarms, etc?. Also , • * ■ ■ triggering only for transactions of a 
certain value or greater (i.e. >$ 100.00) 

■ Loss of Useable Video - This will detect a camera blocked or painted lens situation. This 
feature will probably have a trademarked name as well. 

■ Image Security - We plan to Message Authenticate the image. Most Image Security schemes 
are interested more in Copyright protection. We are more interested in image authentication 
which would allow us to be sure that the image as captured has not been modified since 
capture and initial storage. I suppose we could coin a new name for this, possibly Image 
Authentication Code (IAC). 

■ ATM Servicer Fraud - By configuring this system to detect when the unit is being serviced 
and by triggering image capture at this time, a much higher level of fraud deterrence is 
possible. 



AccuTrack Patents (Cont'd) 
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The unique hardware portion of Accutrack includes 2 Circuit Card Assembly (CCA) with the following 
features: 



■ VIA Board - Ability to remote a group of 12 Cameras with associated 4 alarm inputs and 4 
relay outputs. Selection of specific camera and control of the I/O is controlled via a twisted 
pair. One Coax cable is required to bring the selected video signal back. 

■ VAC Board - Several Functions are combined on this one CCA; Watchdog circuitry, Serial 
control for 2 VIA boards (including video switching, digital input and digital(relay) output 
control ), 4 Serial Ports for transaction monitoring, Control of Front panel indicators and 
switches. 



I believe that we determined that these boards are most probably not patentable. I include them 
here for one last look. 

In addition, we would like to pursue a few Design Patents : 

■ Primary Search Screen 

■ Primary Configure Screen 

■ Primary Welcome Screen 

■ Computer Based Training Entry Screen 

Some of the novel features of the Accutrack System are: 

■ Web-based Server/Browser Technology 

■ Local storage of images with very smart Remote retrieval 

■ Triggering of Image Capture by a variety of means 

■ Built-in Motion Detection 

■ Built-in Loss of Useable Video Detection 

■ Image Security 

We are planning to announce to the general public at the ASIS show the week of 

There are currently two Alpha sites under non-disclosure running prototype Systems. 
A pre-announcement for this product to our sales team will probably precede the ASIS show in 



Please advise of the next step in pursuing the above patents. 



Sincerely, 



JefFEnright 



attachments 



cc: 



Mike Lindroos 
Kevin Martin 
Mike Russell 



Brad Stephenson 



E-89-E 
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E-89-E 
E-68 



